Properties windows implementation
---------------------------------

Each type of item has its own pair of templates for the "main"
and "more" property windows.  These are all loaded at start-up and
the windows are created but not opened.

When an item is selected with the mouse, the properties code chooses
the correct pair of windows according to the item type.  If necessary
it closes the currently open props window(s) and opens the apposite
ones in the same place(s).  It then fills in the window with the
current values.  (This process is deferred if the props windows are
not open).

Events on the windows are handled according to the item type,
and when the OK button is pressed the code needs to cope with
the different item types separately.

Since so many of the fields in the props windows are common,
it is desireable to common up as much of the code as possible.
The mechanism chosen for this is based around name strings in
icon validation strings in the various templates.

Icon names will be numeric, to simplify dispatching, and to keep
things simple we'll only use single icons - not try to use multi-icon
items!  Those icons that appear in all, or many, of the items' props
windows will be assigned global names (starting with "G"; G0, G1 etc).
Icons specific to a particular props window will be given plain
numeric names (0, 1 etc), and these names will be local to that item
type.

The code to fill in a window will look like this:-

for window in (main, more)
        for all the icons in window
                decode name
                is it "Gxx" ?
                        switch (atoi(xx))
                                code to handle each global icon
                                in the cases...
                else if it is "yy"
                        (*fill_in_proc[itemtype]) (window, atoi(yy))
        next
next

Thus the global icons, which always need filling in the same way,
are put in the main switch.  The local ones get handles by a proc
per item type, called through a branch table.

Notes:
1) the handler code does not know whether the item is in the "main" or "more"
   window; this provides some flexibility in moving the items around with FormEd
   without fiddling with the code.  The namespace is shared between the "main" and
   "more" windows.

2) This mechanism is to be preferred over the more obvious one of looping
   over the icons *known* to be in each kind of window.  For one thing,
   it avoids expensive name->icon lookups.  Also, it brings a certain amount of
   flexibility in design of the windows.


The code to dispatch events is similar; the event comes in with window handle
and icon number.  The dispatcher turns this into a pointer into the original
template data (which is out-of-date in many respects, but still has the
name in it), looks up the name, and dispatches in a similar way to the above.
Many of the code fragments will need to do things to other icons, and for this
a certain number of name->icon number lookups will be necessary.  To cut down
the overhead of this we could take the following steps:

1) search the event window first (be it 'main' or 'more') as the affected icon
   is likely to be in the same window as the event icon

2) cache the useful window-handle/icon-number pairs at the "fill in" stage.


The "OK" code may be structured similarly; the main difference might be
that more of the code will need to be done per-item.  However things like
size and name could be done in the "global" section.


If the props windows are open and the user clicks on a different item, any
changes pending are lost.  They are also lost if the user does anything that
requires the windows to be filled in again, e.g. deleting the item, changing its
text by direct manipulation, etc.


----------------------------------------

Global icon names
=================

DEFINE          NAME    PURPOSE                         NOTES
-------------------------------------------------------------
G_NAME          G0      Name entry
G_TEXT          G1      Text of master                  1
G_SPRITE        G2      Sprite of master
G_JUST_L        G3      Justify: Left
G_JUST_R        G4      Justify: Right
G_JUST_C        G5      Justify: Centre
G_WIDTH_DOWN    G6      Width down
G_WIDTH_VAL     G7      Width readout
G_WIDTH_UP      G8      Width up
G_HEIGHT_DOWN   G9      Height down
G_HEIGHT_VAL    G10     Height readout
G_HEIGHT_UP     G11     Height up
G_FONT_VAL      G12     Font name readout               1
G_FONT_MENU     G13     Font name menu button           1
G_FONTSIZE_DOWN G14     Font size down                  1
G_FONTSIZE_VAL  G15     Font size readout               1
G_FONTSIZE_UP   G16     Font size up                    1
G_ICONNUM       G17     Icon number of master icon
G_VALIDATION    G18     Valid. string less "s" entry
G_OPEN_MORE     G19     Pushbutton - open MORE window
G_CLOSE_MORE    G20     Pushbutton - close MORE window
G_CANCEL        G21     Pushbutton - cancel both MORE and MAIN windows, lose changes.
G_OK            G22     Pushbutton - OK the changes, perhaps remove window(s).

Notes:

1) The Group Box has its text in the slave icon.  The text-related
properties need to know about this and handle it specially, or else
duplicate the code in the Group-box-specific code.
